Are duplicates of the response_type, and scope values necessary when using PAR?

[Joseph Heenan]

Part 2 currently says:

shall additionally send duplicates of the response_type,, and scope parameters/values using the OAuth 2.0 request syntax as required by the OAuth and OpenID Connect specifications;

Should this have a “if not using request_uri” qualification? It seems unnecessary to send these if using PAR, given PAR is an IETF spec and can remove (/has removed) the underlying OAuth2 requirement for the duplicates.

[Joseph Heenan]

Actually the latest PAR and https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-26 make clear that client_id is required both inside and outside.

So the question is only about response_type and scope.

[Dave Tonge]

I would agree - although maybe for FAPI 2? I think we left this in for interoperability reasons.

[Joseph Heenan]

I think mostly we were clarifying the existing requirement in OIDC which in turn did it to be technically compliant with OAuth2. (And I think some vendor implementations could not process OpenID Connect requests if those parameters were missing.)

It’d be nice for clients not to have to send scope via the browser if it’s not necessary (though probably the privacy considerations in doing so are minimal in most cases), and it’s potentially incompatible with RAR to require a scope.

I think the expectation would be that people deploying PAR are doing so using vendor support for it (as opposed to attempting to retrofit PAR onto existing authorization server by, say, implementing on a different server in custom code that tries to verify client authentication perhaps by accessing private client management APIs in the AS).

If that expectation is also correct, then I think it’s reasonable to expect the Authorization Servers to be fully compatible with JAR/PAR, so it would be unnecessary for the client to send the duplicates in that case. i.e. when PAR is in use, I don’t think the backwards compatibility arguments apply so much, as PAR is a brand new standard vendors are only now adding support for.

‌

I’d prefer to weaken the clause, at least when PAR is in use.

[Dave Tonge]

That makes sense to me.

I don’t think we should make it conditional though - we can just require client id, in the same way as jwsreq does?

I suppose there could be a problem if an AS who previously gained conformance with FAPI, rejected requests that didn’t have the duplicate params? How would we deal with that?

[Joseph Heenan]

Changing it for the non-PAR case is definitely problematic and likely a breaking change; I’m pretty certain several vendor products that UK banks have managed to get signed request objects working with do require the duplicate parameters, or rather without the duplicate parameters the Authorization Endpoint just won’t get past some of their core processing.

Changing it just for PAR isn’t really a breaking change as the previous implementers draft didn’t include PAR, and because the PAR spec doesn’t require the duplicates to be sent. Or put another way, one way of viewing it is that when we added PAR to FAPI we accidentally ended up with the statement about duplicates applying to PAR.

‌

[Dave Tonge]

Yep - I see.

So how about this:

shall additionally send duplicates of the response_type, client_id, and scope parameters/values using the OAuth 2.0 request syntax as required by the OAuth and OpenID Connect specifications, unless using [PAR] in which case only the client_id shall be duplicated.

‌

We should probably check if any other clauses need adjusting

[Joseph Heenan]

Thanks Dave - your suggested wording sounds good.

‌

I had a scan through and no other clauses leapt out a problematic.

‌

The only thing that does occur to me is that we could make a transition to FAPI 2 easier by suggesting that when using PAR clients should send PKCE, regardless of whether the server supports it or not. Or we could just mandate PKCE when using PAR, it wouldn’t be a breaking change due to the previous draft not mentioning PAR. (If you remember I believe we almost made PKCE mandatory in FAPI-RW, due to many clients not checking s_hash and hence not actually getting the protection s_hash provides - the major reason we didn’t do so was that we didn’t want to impose a breaking change on the UK ecosystem.)

[Joseph Heenan]

I’ve created a new issue to cover the PKCE discussion: https://bitbucket.org/openid/fapi/issues/307/fapi-rw-require-pkce-when-using-par

[Nat Sakimura]

Are we done with the discussion?

[Joseph Heenan]

yes, I think we agreed this - I raised https://bitbucket.org/openid/fapi/pull-requests/188/clarify-that-duplicate-parameters/diff to updated the spec, which I think is ready to be merged.

[Dave Tonge]

Merged in par-duplicates (pull request #188)

Clarify that duplicate parameters requirement doesn't apply to PAR

• Clarify that duplicate parameters requirement doesn't apply to PAR

As per discussion here:

https://bitbucket.org/openid/fapi/issues/304/are-duplicates-of-the-response_type

with fixed c&p error & clarified language as per comments from Brian Campbell

closes #304

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Nat Sakimura

→ <<cset 0b6071d0d932>>